#	$OpenBSD: README,v 1.5 2003/07/09 07:44:29 tedu Exp $
#
# Copyright (c) 1993 Terrence R. Lambert.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in the
#    documentation and/or other materials provided with the distribution.
# 3. All advertising materials mentioning features or use of this software
#    must display the following acknowledgement:
#      This product includes software developed by Terrence R. Lambert.
# 4. The name Terrence R. Lambert may not be used to endorse or promote
#    products derived from this software without specific prior written
#    permission.
#
# THIS SOFTWARE IS PROVIDED BY TERRENCE R. LAMBERT ``AS IS'' AND ANY
# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED.  IN NO EVENT SHALL THE TERRENCE R. LAMBERT BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
#

0.0	README

	README file for the loadable kernel modules interface.

	Direct questions and comments to:

		Terry Lambert
		terry@cs.weber.edu

	Please do *not* mail me at Novell.


1.0	About this build hierarchy

	This is the build hierarchy for the loadable kernel modules
	(lkm) command line interface and test suite (including a
	set of sample code for each possible module type).

	The procedures in this file assume you have installed the
	kernel portions of the lkm system and have rebooted your
	machine so that they are ready for use.

	If you have not done this, then there is no reason for you to
	continue; please take the time to install the lkm system into
	your kernel at this time.


2.0	Compiler warnings

	Some compiler warnings will occur due to inclusion of kernel
	and non-kernel header files in the same program that have had
	the same function names ANSIfied and the prototypes for the
	kernel and libc functions conflict.  This needs to be resolved
	by fixing the header files, which I haven't bothered to do (the
	main conflict was "printf", and I made a dirty hack to get
	around it until the header files have been fixed).


3.0	Usage warnings

	Loading a bogus module will kill your machine, but if you are
	doing development, this will end up happening (hopefully)
	less frequently than changing, recompiling, installing, and
	rebooting would normally occur.  This should speed development
	considerably for a lot of the in-kernel work that is currently
	taking place.


4.0	Loadable module types supported

	There are six loadable modules types supported; five of these are
	specific module types; the sixth is to allow the user to make
	their own loader as part of the module and allow them to replace
	or extend appropriate tables in the kernel.


4.1	System call modules

	System calls as loadable modules use one of two approaches.

	If the system call slot is unspecified (-1), it will attempt
	to locate (and allocate) the next free call slot that points
	to the address of the "lkmnosys" function (an alias for the
	"nosys" function).  It replaces this with the user's call;
	the user can tell which slot was allocated using the "modstat"
	command (the call slot is indicated by the value of "Off").

	If the system call slot is specified, it will replace that
	specific call (assuming it is in range of the entries in the
	sysent[] table).  Care should be taken when replacing system
	calls.  Good candidates are calls that the user is attempting
	to repair or make POSIX compliant.  It is possible to replace
	all calls, although care should be taken with the "ioctl()"
	call, as it is the interface for the lkm loader.

	When unloaded, the system call module replaces the previous
	contents of the call slot.  If this was an allocable slot, it
	is now reallocable; if it was a particular call slot, the
	previous function is restored.

	The directory ./sample/syscall contains a sample implementation
	of a loadable system call.


4.2	Virtual file system modules

	A virtual file system can be loaded as a module.  The example
	provided is for the "kernfs" file system; this is the code in
	NetBSD's /sys/kernfs combined in a single object with another
	piece of code giving a module entry point for the file system;
	with very little effort, any file system can be set up this way
	(although I suggest you leave "ufs" statically linked, since
	it is necessary for booting).

	The critical section of loading a VFS is to get the entry in
	the right slot and mounted.

	Because of the dependency on the vfssw[] table index during
	the mount, we can't simply mix and match file systems except
	in their predefined locations with regard to mount.  This
	means that there are changes to vfssw[] and mount coming
	down the road (which will end up incrementing the lkm version
	and introducing an incompatibility as far as file system modules
	are concerned).

	The directory ./sample/vfs contains the sample implementation
	of the loadable kernfs vfs.


4.3	Device driver modules

	The major issue to deal with when creating device drivers is
	ensuring the creation of the device node.  The current approach
	to this is executing a module specific shell script upon a
	successful load.

	A potentially better solution is encoding the device name in
	the device switch, or, better, providing a functional interface
	to the init routine, and then using a "/devices" file system
	to export devices to the file system name space.  Of course,
	the default "/dev" directory would have to be maintained for
	compatibility (probably using symbolic links).

	This distribution does not contain a loadable device driver
	example.  A potentially beneficial example could be made of
	the "lpa" interruptless printer driver.


4.4	Streams modules

	Streams module support has been removed from this release; when
	the streams implementation is ready, it will be restored as a
	patch.

	Please do not ask me for early availability on my streams
	implementation; until I have some non-proprietary modules
	to distribute, I'm putting work on it on the back burner
	while I finish shared libraries.


4.5	Execution interpreters

	Execution interpreters allow loading of programs with magic
	numbers other than the default numbers supported by NetBSD.
	This allows user space development of changes in exec format
	to support, among other things, shared libraries.

	Another potential use requires changing the references to
	the "sysent[]" system call table from direct references to
	indirect through a pointer in the proc struct.  This allows
	the execution interpreter to, among other things, support
	(statically linked) executables from other environments,
	like XENIX, SVR3, SVR4, and Linux.

	There is no example of a loadable execution interpreter
	provided with this distribution.


4.6	Miscellaneous modules

	Miscellaneous modules are modules for which there is not a
	current, well-defined, or well-used interface for extension.
	They are provided for extension, and the user is expected to
	write their own loader to handle the kernel pointer/table
	manipulation to "wire in" their loaded module (and "unwire"
	it on unload).

	One example of a "miscellaneous module" might be a loader for
	card-specific VGA drivers or alternate terminal emulations in
	an appropriately layered console driver.

	The table manipulations required are specific to the console
	interface, yet a loadable module may be used if code is written
	to tell it how to manipulate the interfaces within the internal
	console interfaces.

	An example of a "miscellaneous module" is provided to show how
	to write "miscellaneous modules"; it duplicates the functionality
	of the "system call" module type, and is not intended to be
	seriously used, as it could interfere with the "system call"
	module type.  The sample code is located in ./sample/misc.



5.0	END OF DOCUMENT
